PagerDutyにAmazon GuardDutyを統合してアラートを通知させてみた

みなさん、こんにちは。

明るい笑顔がトレードマーク、ルイボスティーが大好きな芦沢(＠ashi_ssan)です。

みなさん、インシデント管理していますか？

AWS上のシステムを安定稼働させるために、サーバーメトリクス、ログ、セキュリティなどをはじめとした項目の監視は必須ですよね。

AWSにおける監視サービスといえばCloudWatchがありますが、リソースを監視をより楽にするツールはAWS以外にたくさんあるため、運用負荷を軽減するためのツールの導入を進めていくとアラートを検知した際の通知や煩雑になってきます。

さらに、インシデントが起きた際はさまざまな監視ツールでアラートが検知されることもあると思います。その度複数のツールを行き来していると疲弊してしまうでしょう。

そんな時役に立つのがインシデント管理SaaSのPagerDutyです。

PagerDutyとは？

PagerDutyは、システムのインシデント対応を一元化できるプラットフォームです。

AWSを含むさまざまなツールと連携してインシデント発生時のチケット管理、通知(電話、メール、SMS、アプリ)、アラート通知先のシフト管理などの総合的な機能が簡単に手に入ります。

今回PagerDutyとAWSのマネージド型脅威検知サービスであるAmazon GuardDutyを統合し、アラートの通知の流れを体験してみます。

検証について

今回行う手順はPagerDutyのKnowledge BaseにあるAmazon GuardDuty Integration Guideを参考に実施しています。

前提として、以下2点やっておく必要があるため、各自の環境でご準備ください。

• PagerDutyのトライアルアカウントを発行済みでログインできること
• Administrator権限で利用可能なAWSアカウントでGuardDutyを有効化済みであること

それではここから検証を開始していきます。検証は以下の流れで実施します。

• PagerDuty側の設定
• AWS側の設定
• アラート通知テスト

PagerDuty側の設定

PagerDuty Serviceとの統合設定

PagerDuty Service Directory のページからService Directory を作成します。

New Serviceから作成します。

任意のサービス名を入力してください。

ここでエスカレーションポリシーを設定します。

エスカレーションポリシーはインシデント発生時に誰にどんな順番で通知を送るのかを定義するためのルールです。

今回は以下のようなポリシーを設定しています。

• インシデントが発生した時即時で
• 自分のみを宛先に30分おきに通知をする
• インシデントが受任されなかった場合3回繰り返す

続いて、インシデントのノイズ削減に関する設定を行います。

Alert Groupingでは、短時間に似たアラートを検知したときのグルーピング設定、Transient Alertは時間によって自動解決されるアラートを検出し通知を自動的に一時停止する設定です。

どちらもデフォルトで5分が設定されており、今回はそのまま設定します。

Integration設定でAmazon GuardDutyを検索し、指定します。

Serviceが作成完了すると、GuardDutyとの統合で利用するIntegration URLが発行されます。後ほど使うので控えておいてください。

これでPagerDuty側の準備ができました。

AWS側の設定

SNS トピックとサブスクリプションの作成

AWSマネジメントコンソールから、SNSトピックを作成します。

タイプはスタンダードを指定し、任意の名前を入力してください。

トピック作成後、サブスクリプションを作成します。

プロトコルにHTTPを指定し、エンドポイントにはPagerDutyのService Directory設定後に表示されたGuardDutyのIntegration URLを入力してください。

rawメッセージ配信の有効化　オプションは、今回のようなService Directoryの統合のケースでは無効化のままにします。

サブスクリプションが作成できました。正しく設定できていれば、サブスクリプションのステータスがすぐ確認済みになるはずです（ならない場合はコンソール画面を更新してください）

EventBridge ルールの作成

続いて、EventBridgeのコンソールからEventBridgeルールを作成します。

任意の名前を入力し、イベントバスはdefault、選択したイベントバスでルールを有効にするオプションは有効化、ルールタイプはイベントパターンを持つルールを指定します。

イベントソースはAWS イベントまたは EventBridge パートナーイベントを選択、イベントパターンはAmazon GuardDuty、イベントタイプはGuardDuty Findingsで設定してください。

ターゲットタイプはAWSのサービスで、ターゲットを選択でSNSトピックの前述の手順で作成したトピックを指定します。

その後のオプション設定は任意で指定し、ルールを作成します。

ここまでで準備は完了です。

アラートの通知テスト

GuardDutyでアラートを検知させ、想定通りアラートがPagerDutyに連携されるかテストしてみます。

イベントを1件だけ発行

まずは1件だけアラートを発行してみます。

こちらのブログを参考に、重要度:高のイベントを1件発生させます。

aws guardduty create-sample-findings \
  --detector-id $(aws guardduty list-detectors --query 'DetectorIds[0]' --output text) \
  --finding-types "Backdoor:EC2/DenialOfService.Dns"

CloudShellなどでコマンドを実行すると、GuardDutyコンソール上にサンプルイベントが記録されます。

イベント発行からしばらく待つと、PagerDutyダッシュボード上に以下のようなインシデントが記録されました。メール・SMS・電話通知もダッシュボード上の記録とほぼ同時タイミングでした。

メール通知はこんな感じ。英語表記のみですが、ステータスやサービス、担当者などがまとまっていて一目でわかるような構成になっています。

SMSでは、このように通知されます。情報が少なく、英語だけなので読みづらいかもしれない

電話通知はスクショはありませんが、インシデントのタイトルが英語で読み上げられました。正直あまりわかりませんでした。

※参考までに、環境にもよると思いますが、AWS側のイベント発行とPagerDutyへのアラート通知のラグは３-4分でした。

インシデントを検知したら、まずは「私が対応する」という意思表明をするために、Acknowledge(受任)します。

受任するとステータスが更新されます。

インシデント画面を眺めてみます。

Alertタブでは、Custom Detail欄にGuardDuty検出結果画面に記載されている情報が簡単なテーブル形式で表示されています。AWS環境にログインしなくとも実際の検出結果についての詳細情報が確認できてとても便利そうです。

Status Updateタブでは、ビジネスサイド向けに作成するインシデントに関するステータスダッシュボードを管理できるそうです。

Timelineタブでは、ここまでのインシデントの状態遷移の履歴が確認できました。

現状は、インシデントがトリガーされ、私宛に通知が発行され、インシデントが私によって受任されたところまでが記録されています。

Past Incidentタブでは過去に発生した類似のインシデントが確認できます。

後述するイベント大量発行に検証を先に実施したため、その時に検知したものが過去の事象として記録されています。

対応が完了したら、チケットのインシデントのステータスをResolveにします。

イベントを大量に発行

続いて、大量のサンプルイベントを発行してみます。

GuardDutyコンソールの設定 > 検出結果サンプルの生成 からサンプルイベントを発行できます。

発行されたサンプルイベントは、GuardDutyコンソール上で確認すると164件であることがわかりました

。

しばらく待つと、PagerDuty側にもアラートが通知されました。

PagerDurt側のインシデント数が45件とAWS側と一致していないのは、おそらくReduce Noise機能によってインシデントがまとめられたからだと想定してます。

GuardDuty Finding: S3 API GeneratedFindingAPIName was invoked from known malicious IP address 198.51.100.0.という名前のサンプルイベントが3件検知されており、それらは1つのインシデントにまとめられていました。同じタイミングで同じようなアラートが複数起きることはよくあるので、こういった同件だと思われるアラートをサービス側で1つにまとめてくれると大変嬉しいですね。

インシデントをTriggeredの状態のままにしてしまうと定期的に通知されてしまうため、忘れずにステータスをResolvedに変更しておきます。

Incidents画面からだと、現在起きているインシデントとそのステータスがまとめて確認でき、ステータスの一括変更も簡単にできました。

検証は以上です。

おわりに

今回はPagerDutyにGuardDutyを統合し、実際にアラート検知させるところまでをやってみました。

SNSトピック + EventBridgeルールの作成というAWSとしては慣れ親しんだベーシックな構成なので、簡単に構築できました。

まだ導入できておらず挙動を確認できていませんが、PagerDutyはWebアプリだけでなくモバイルアプリでも利用可能です。インシデント運用の体験としてその存在がかなり大きいと伺っているので、今後試してみたいです。

以上、芦沢(＠ashi_ssan)でした。